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Abstract 

NASA is particularly concerned with reducing 
mission operations costs through increased 
automation. This paper examines the operations 
procedures within NASA Mission Control Centers in 
order to uncover the level 
of automation that currently exists within them. 
Based on an assessment of mission operations 
procedures within three representative control 
centers, this paper recommends specific areas 
where there is potential for mission cost reduction 
through increased automation. 

Introduction 

In order to determine the procedures 
followed and the level of automation that exist 
within three representative NASA Mission Control 
Centers, the three basic functions performed by 
their respective flight operations teams were 
studied. This specifically included their methods 
for performing real-time monitoring and 
commanding, mission planning, and offline trend 
analysis. 

Overall, there are varying degrees of 
autonwition within the NASA Mission Control 
Centers. The level of automation that Is achieved is 
largely dependent on the level of complexity of the 
mission, as well os the capabilities of the ground 
system that they use. Larger missions tend to be 
less automated than smaller missions. This is not 
only due to technical barriers within the operations 
of larger missions, but it is also due to political 
barriers in autonwting the more costly and highly 
visible missions. 

This paper will summarize current mission 
control procedures and suggest three specific areas 
for potential cost reduction through increased 
autonwtlon. 

Commanding the Spacecraft 

Commanding the spacecraft refers to the 
signals or telemetry that arc sent between the 
Mission Control Center and the spacecraft's on- 
board software. Specifically, this is comprised of 


the uplinks performed for sending commands and 
memory loads to the spacecraft and the downlinks 
performed to download health and safety and 
science data from the spacecraft. Uplinks or 
forward links provide the on-board system with 
instructions for spacecraft operations such as 
instrument pointing. The number of times per day 
that uplinks are required for sending comn\and loads 
depends on the amount of commands required to 
operate the spacecraft and instruments and the 
amount of nf\cmory available on the spacecraft for 
storing commands. [>ownlinks arc performed by 
downloading engineering and science data to the 
Mission Control Center either in real-time mode or 
by downloading stored data from the on-board solid 
state recorder. Real-time downlinks occur by 
directly transmitting telemetry data to the ground 
during a real-time support with the spacecraft. 

Solid state recorder downlinks occur during a real- 
time support as well, but the data that is 
downloaded has been previously stored on the 
recorder during times when the spacecraft is not in 
view of a ground station. 

The spacecraft is typically controlled by 
cither executing rcal-tin\e or stored comnwinds. 
Stored commanding is the most common method and 
involves the development of pre-planned command 
loads that arc sent to the spacecraft's stored 
command processor during contacts with the ground 
system. Each stored comnvand is programmed to 
execute at a specific time to perform 
predetermined tasks. Real-time commanding 
involves the Flight Controller directly controlling the 
spacecraft by sending it comnwinds that are 
executed by the spocecraf t immediately upon 
receipt. Real-time commanding is typically 
perfornoed for routine activities where the Flight 
Controller requires feedback from the spacecraft 
(i.e., telemetry) while commanding. Examples might 
include managing the dumping of the on-board 
recorder and performing maneuvers. In certain 
emergency situations, such as when the spacecraft's 
state of health is in danger and there is no time to 
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generate a stored command load, the Flight 
Controller may need to utilize real-time commanding. 

There are two different methods used as a 
communication link between the spacecraft and the 
Mission Control Center: ground stations and the 
Tracking A Data Relay Satellites (TDR5). Ground 
stations are communication stations that are located 
all over the world and serve as the first 
communication point for the transmission of 
telemetry data from satellites to the ground 
system. The TDR5 satellites are a constellation of 
six satellites which form the space-based portion of 
NASA’s Space Network that support communication 
with other satellites from space. Requests for the 
use of any of the TDRS satellites are scheduled 
through the Network Control Center (NCC). 

Mission Planning 

Mission planning involves all of the 
activities required to plan for the contacts with the 
spacecraft. Specifically, this involves the 
coordination between different organizations to 
schedule the use of either TDRS or a ground station 
during times when a particular satellite is in view. 
Typically, Mission Control Centers use a flight 
dynamics system to generate orbit data that is 
factored into the communication schedule. 

Additionally, mission planning involves 
building the commands that are sent to the 
spacecraft to control and instruct it. For large 
missions, there is a separate mission planning team 
that is responsible for coordinating the schedule for 
contacts with the spacecraft and building the 
comnvand loads. For smaller missions, these 
functions are typically pcrfornftcd by the Flight 
Controllers. 

Trend Analysis 

Trend analysis is the analysis of 
spacecraft engineering telemetry data for the 
purpose of predicting potential anomalies that may 
occur in spacecraft components. Analysis of this 
data must be performed regularly to ensure that the 
science instruments arc operating properly so that 
they can make accurate observations. Additionally, 
this analysis may prevent unsafe conditions which 
could cause the loss of an instrument or other 
component. The telemetry data typically gets 
automatically transferred from the ground system 
to an analysis system within the Mission Control 
Center that archives and stores it. Various types of 
statistical reports nwy be run by retrieving and 
plotting this data. 

Mission Observations/Interviews 

Three representative NASA Mission 
Control Centers were observed in order to analyze 
their daily operations by physically sitting with the 
Flight Operations Teams and documenting their 


activities. Interviews were also conducted with 
team members to elicit feedback. The missions 
studied were: the Small Explorer (5MEX) missions, 
the Earth Observing System (EOS) Terra mission, 
and the Hubble Space Telescope (HST) mission. A 
summary is provided of each mission's procedures 
and level of autorrwition. 

Small Explorer (SfAEX) Missions 

The SMEX Mission Control Center is 
considered a multi-mission facility; each mission 
operates independently, yet consistently. The 
missions that are supported by this Control Center 
are: Wide- Field Infrared Explorer (WIRE), 

Transition Region and Coronal Explorer (TRACE), 
Submillimeter Wave Astronomy Satellite (SWAS), 
and Solar Anomalous and Magnetosphcric Particle 
Explorer (SAMPEX). 

Their nominal staffed operations are for 8 
hours a day, 5 days a week. They are not required to 
support a 24-hour a day, 7-day work week due to the 
level of automation that they have achieved in 
support of these missions. They have successfully 
automated the conduct of all of their spacecraft 
contacts, which includes configuring the spacecraft 
and ground system for the contact, dumping the 
solid state recorder, and monitoring the real-time 
health and safety data. However, they do still 
manually transmit their comnvand loads. 

The ground system that all four of the 
SMEX missions use to support their mission 
operations is the Integrated Test and Operations 
System (ITOS). The primary communication links 
between the spacecraft and ITOS are the Wallops 
Island and Poker Flat ground stations. These 
missions also rely on the Spacecraft Emergency 
Response System (SERS) to page the appropriate 
engineer if the ITOS system detects a potential 
problem in the spacecraft data that is auto nrvati cal ly 
downloaded during off-duty hours. The ITOS 
interfaces with the SERS to execute this process. 

The SMEX mission planning function is 
perfornved nvanually by the Flight Controllers. The 
system that they use to build their comnvand loads is 
the Command Management System (CMS). The Flight 
Controllers prepare their own comnvand loads using 
the CMS to build them. Although the CMS 
simplifies the building of the comnvand loads, it 
appeared that nvany of the tasks performed were 
performed manually, such as the retrieval of the new 
procedures and the transfer of the old procedures 
to an archive directory within the system. The 
communication schedule for spacecraft contacts is 
prepared by the Wallops Planning System network 
and a weekly schedule is sent to the SMEX facility. 

The trend analysis system that SMEX uses 
Is the Data Trending and Analysis System (DTAS). 
The ITOS system provides DTAS with the 
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telemetry data that it gathered and processed 
during contacts with the spacecraft. The data is 
used to make predictions by looking at overall 
trends. The team notes degradation in equipment 
and predicts failures with these reports. DTA5 has 
successfully automated some of the reporting that 
is performed by these missions, such as 
autonwtically performing their daily trending plots. 

In general, the SMEX missions are much 
more automated than the other missions that were 
studied. This can be attributed primarily to their 
ground system, ITOS, which provides them with the 
capability of automating their commanding and the 
relative simplicity of operating the missions. ITOS 
was used to its fullest capacity for the Fast Auroral 
Snapshot Explorer (FAST) mission that has now 
been moved to Berkley, CA. This mission was fully 
autonomous, except for their mission planning, for a 
month before it was moved. The engineers 
supporting this mission attribute its success to the 
stability of the spacecraft and the number of 
opportunities for making contact with it. The 
greater the number of opportunities for contacts, 
the safer automation is for a particular mission in 
that if errors occur in a transmission, there are 
more opportunities to recover or resend any lost 
data. Therefore, the greatest barrier for further 
automation of the commanding for the other SMEX 
missions is that there are problems at times with 
lost data that tends to occur at the ground stations. 

Hubble SoQce Telescope (HST) Mission 

HST is considered a Great Observatory 
mission, which is designated by NASA as a long term 
space-based general observer facility, bue to the 
size and public exposure of this mission, it is heavily 
nvinned and most of their operations arc performed 
manually. The team supports 24 hour a day, 7 days a 
week nominal operations. 

The HST Flight Operations Team (FOT) 
uses the Control Center System (CCS) as their 
ground system. Hubble typically uses one of the 
TbRS satellites as its primary communication link to 
CCS. The commanding that they perform through 
CCS is still for the most part manual in that all of 
the contact with Hubble to send command loads to 
the spacecraft are performed by the Flight 
Operations Team. Their command loads that 
support a 24-hour timeperiod include procedures 
that execute at predefined times to downlink 
engineering and science data. The monitoring of the 
engineering data is performed manually 24 hours a 
day by the Flight Operations Team. 

The HST mission planning function is now 
performed at the STScI, therefore a thorough 
study of this function was outside the scope of this 
study. 


The Hubble trend analysis function is a 
fairly manual process. The Hubble System 
Engineers perform the analysis of this engineering 
data daily by extrapolating telemetry data from the 
electronic data warehouse in CCS to run reports. 
They import the data into cither Microsoft Word or 
Excel and manipulate it according to the type of 
report they need to run and develop their own 
reports. The trend analysis function is definitely a 
candidate for further automation, as it requires the 
engineers to perform most of this work manually. 

The lack of autonwtion in Hubble's flight 
operations does not appear to be for technical 
reasons. Rather, it is more of a perceived political 
impact that prevents further automation. To a 
certain extent, their continued manual processes can 
be attributed to the high visibility of this mission, 
the impact to the science community if observation 
time is lost, the spacecraft changes that occur with 
each servicing mission, and the risk of damaging 
publicity if anomalies occur or data is lost during an 
automated pass. There are plans for upgrading their 
ground system sometime in the future to increase 
their levels of automation, particularly once 
servicing missions are no longer planned. 

Terra Mission Control Center 

The Terra Mission Control Center is part 
of NASA's Earth Sciences Enterprise (ESE) and is 
one of the Earth Observatory missions. It is also a 
very large mission and is comparable in size and 
complexity to Hubble. It has some of the same 
constraints with regard to autonwtion as Hubble 
does due to its visibility and size. Although, the 
Terra Flight Operations Team is considering the 
implementation of further automation into their 
operations, currently all of their communication with 
the spacecraft is still performed manually. The FOT 
also manually monitors Terra's engineering data 
continuously throughout the day. The team supports 
24 hour a day, 7 days a week nominal operations. 

The ground system that the Terra Flight 
Operations Team uses to support their real time 
commanding and monitoring is the Eclipse system. 
The primary communication link between the 
spacecraft and Eclipse are the TDRS satellites. 

The Terra mission planning function is 
supported by a team of people that are responsible 
for developing the following planning products: the 
Detailed Activity Schedule, which is a daily schedule 
that outlines all on-board activities for the next day, 
the NCC schedule request for TDRS supports, the 
ground station schedule request, the command loads 
prepared for uplinking to Terra, and several 
different types of reports for engineer and FOT 
review. 

They perform these tasks using the 
Mission Management System (MMS) to develop their 
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planning products. AAAAS docs provide the planning 
staff with a certain level of automation that 
simplifies the preparation of these products and it 
will generate routine stored command sequences 
automatically. However, there are still many tasks 
that require some labor-intensive work by the 
planning staff and that could be further automated. 
As an example, the planning team must execute the 
scripts that automate their processes by entering in 
several UNIX commands in multiple UNIX terminal 
sessions. All in all, further automation of the mission 
planning process would simplify these procedures for 
the planning staff, although they have made definite 
strides in automating a great deal of their tasks. 

The trend analysis system that is used by 
the Terra engineers is supported by the Epoch 2000 
system, which performs the tclenoctry processing, 
and the Archive Browser and Extractor (ABE) 
system. ABE is used to retrieve and analyze the 
Terra engineering data and to generate trending 
reports. The ABE system automatically generates 
batch reports on a daily basis for the engineers to 
review. In most cases, the engineers use the ABE 
system themselves and generate their own reports. 
Some of this daily routine reporting performed by 
the engineers could be further automated. 
Furthermore, all of the analysis and predictions 
made by the engineers is performed manually. If 
the analysis of this data were automated, more of 
the data could be analyzed and the process of 
predicting potential anomalies would become much 
more efficient. 

On the whole, additional automation for 
the Terra FOT could significantly improve their 
processes. Originally, they had planned to implen^ent 
a system called the Flight Operations Segment 
(FOS). which would have automated more of their 
comrtwnding, however this system was very 
unreliable and had to be replaced with the current 
Eclipse system one year before the launch of Terra. 
One of the barriers to automating more of their 
commanding processes is that the Eclipse system 
must interface with other systems to perform 
typical ground system functions. Increasing the 
degree that their systems are integrated could 
greatly facilitate the incorporation of increased 
automation throughout the system. Another barrier 
that Inhibits additional autonvation within the FOT is 
that the data rates for communication between the 
solid state recorder and the Terra instruments vary 
throughout the day, depending on instrurrvent 
activities. It would be very difficult, if not 
Impossible, to model this dynamic process with the 
current Eclipse system. 

Conclusion 

Overall, the larger missions (Terra and 
Hubble) were much less automated than the smaller 


missions (SMEX). This is not only due to technical 
barriers, such as the limitations of their ground 
systems, but it is also due to the higher complexity 
and visibility, as well as the unique culture of the 
larger missions. 

The capabilities of the ground system that 
are used by the mission are a major factor that 
determines the level of automation. For example, 
the ITOS system used by the SMEX missions 
provides the capability of fully automating their 
commanding. On the other hand, the CCS system 
used by Hubble does not currently provide this 
capability and neither does the Eclipse system that 
is used by Terra. 

Additionally, cultural and political barriers 
determine the level of automation as well. For 
example, in all of the missions that were studied, it 
was difficult for the engineers that support flight 
operations to fully trust an automated system to 
perform the critical function of communication with 
the spacecraft. There are legitimate concerns for 
the loss of data during an automated transmission 
that may not be recoverable if an engineer is not 
alerted to the problem in time. In the case of the 
larger missions, missing data would be very politically 
danwging and could impact funding for the project. 
However, for the smaller missions, these Issues arc 
not as much of a concern. 

There arc three potential candidates for 
further automation within flight operations. First, 
the mission planning systems for each of the 
missions studied all provided sonve level of 
automation for building schedules and command 
loads, but they all still tended to require a great 
deal of nwinual transferring of files, preparation of 
reports, etc. Second, the trend analysis functions 
for each mission are still rtwnual to semi -automated 
in nature. While Hubble does not even have a 
dedicated trend analysis system, the SMEX and 
Terra folks have dedicated systems but there are 
still a fair arrwunt of manual reporting that is 
performed. The analysis and predictions of the data 
that are trended is performed manually for all of 
the three missions. Lastly, commanding could also 
be further automated, especially for those missions 
that still perform manual commanding for the 
downlinking of data. The uplinking of comnrwnd 
loads could be autonxited as well if the mission lends 
itself to this level of automation. 
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